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Software  is  a  product .  .  .  NOT! 


Much  of  our  planning  for  software 
uses  the  hardware  product  model. 
While  we're  not  perfect,  we  do  a  fairly 
good  job  of  managing  hardware  engi¬ 
neering  for  required  time,  quality,  and 
money.  But  software  more  often  than 
not  is  late,  doesn’t  do  what  we  want  it 
to  do,  and  costs  too  much.  And  that's 
a  problem. 

We  can’t  see  a  solution  to  our  prob¬ 
lem  —  perhaps  because  we  have  made 
the  solution  invisible  by  thinking 
about  it  in  the  wrong  terms. 

I  propose  a  vocabulary  change.  We 
will  better  understand  the  process  if 
we  consider  software  as  a  service,  not 
a  product.  Let  me  expand  on  this 
statement. 

1  do  not  believe  we  must  do  any  of 
the  software-building  activities  differ¬ 
ently.  Instead,  from  the  perspective  of 
scheduling,  budgeting,  and  delivering 
software,  we  should  use  the  service 
paradigm  rather  than  the  product 
paradigm. 

Hardware  versus  software.  We’ve 
all  pondered  the  ways  in  which  soft¬ 
ware  differs  from  hardware; 

•  After  initial  development,  most 
hardware  cost  is  in  manufacturing. 
Software  has  a  small  manufacturing 
cost. 

•  Hardware  has  physical  parts  that 
wear  out,  but  can  be  replaced  with 
identical  or  improved  parts;  the  physi¬ 
cal  environment  seldom  changes.  Soft¬ 
ware  parts  do  not  wear  out,  but  often 
need  replacement  with  greatly  im¬ 
proved  parts  for  changing  environ¬ 
mental  requirements. 

•  After  initial  development,  hard¬ 
ware  requires  few  engineering  person¬ 
nel  for  product  maintenance.  Software 
needs  many  highly  skilled  software 
engineers. 

•  Hardware  is  difficult  and  expen¬ 
sive  to  change  in  the  field.  Software 
can  be  upgraded  easily  and  inexpen¬ 
sively  in  the  field. 

•  Hardware  engineering  has  ma¬ 
tured  into  a  craft.  Software  engineer¬ 
ing  still  has  a  long  way  to  go. 

Hardware  matches  our  notion  of  a 


product.  But  does  software?  Can  we 
do  better  with  a  service  paradigm? 

Software  as  a  service.  What  is  a  ser¬ 
vice  paradigm?  Service  is  intangible. 
Software  provides  a  delivery  system 
for  results.  Users  of  our  software  do 
not  cave  what  program  they  have  for  a 
word  processor,  spreadsheet,  or 
graphics  editor.  They  want  results:  a 
proposal,  a  financial  statemen',  or  a 
presentation  slide. 

A  service  is  successful  when  the 
customer  wants  to  continue  using  it. 
Under  my  proposal,  our  emphasis 
would  change  from  building  and 
maintaining  a  product  to  providing 
the  service  users  need  to  do  their  jobs. 

We  must  plan  and  budget  our  efforts 
toward  reaching  this  goal.  And  we 
should  teach  customers  this  same  atti¬ 
tude  for  acquiring  and  using  software. 

Upgrades  as  service.  When  the  soft¬ 
ware  industry  began,  everything  was 
free.  Manufacturers  gave  away  soft¬ 
ware  to  sell  machines.  Users  freely 
shared  software.  Eventually,  we  real¬ 
ized  we  could  make  money  from  soft¬ 
ware  by  treating  it  as  a  product.  Com¬ 
panies  began  charging  for  software, 
although  they  seldom  sold  it.  Instead 
they  leased  or  licensed  it  for  a  fee.  of¬ 
ten  with  a  maintenance  charge. 

As  personal  computers  came  along, 
software  truly  became  a  product. 

Now,  we  can  go  into  a  store  and  buy 
software  off  the  shelf.  We  own  it  (no 
matter  what  the  “license  agreement’’ 
says)  and  can  use  it  forever  without 
ever  paying  any  more. 

But  computer  hardware  capabilities 
keep  increasing  and  we  demand  soft¬ 
ware  improvements.  Competitors 
appear,  selling  fancier  versions  of 
products.  Companies  enhance  their 
products  and  sell  "upgrades  ’  through 
the  mail. 

With  much  fanfare,  Microsoft  start¬ 
ed  selling  its  5.0  upgrade  to  MS-DOS 
in  stores.  Soon,  most  firms  were  sell¬ 
ing  upgrades  —  not  only  to  their  own 
products,  but  also  as  replacements  for 
their  competitors’  products.  Upgrades 
appeared  on  the  best-selling  software 
lists.  Customers  became  accustomed 


to  (but  not  necessarily  happy  with) 
paying  for  a  product  and.  at  intervals, 
its  upgrades.  The  pricing  scheme  be¬ 
gan  to  resemble  that  of  a  service  like  a 
book  or  record  club. 

The  next  stage?  Because  companies 
complained  about  the  need  to  contin¬ 
ually  purchase  upgrades,  Microsoft 
announced  that  it  would  begin  an  up¬ 
grade  subscription  service  —  much 
like  a  magazine  subscription. 

So  we’ve  moved  from  software  as  a 
free  service  to  software  as  a  paid  sub¬ 
scription  service.  In  all  these  modes, 
we  call  it  a  product.  But  lurking  in  the 
background  is  that  idea  of  software  as 
a  service,  not  a  product.  And  if  we 
plan  and  manage  it  as  such,  we  might 
have  a  better  hold  on  planning,  sched¬ 
uling,  and  performing  its  activities. 

Avoiding  maintenance.  An  interest¬ 
ing  thing  happens  when  software  is  no 
longer  a  product.  We  no  longer  main¬ 
tain  it. 

We’ve  often  said  that  software 
maintenance  differs  from  hardware 
maintenance.  Instead  of  keeping  parts 
that  wear  out  from  failing,  software 
maintenance  now  embodies  fixing  er¬ 
rors  and  enhancing  software  for  new 
requirements  or  environments.  But  if 
software  becomes  a  service,  we  em¬ 
phasize  adjustments  for  flaws  as  they 
appear  and  expansion  to  new  and  im¬ 
proved  facilities. 

What’s  the  difference?  It’s  a  matter 
of  attitude.  With  the  attitude  that 
software  is  a  continuing  service,  we 
plan  and  budget  for  what  was  called 
maintenance  as  part  of  that  service  in¬ 
stead  of  tacking  it  on  as  a  necessary, 
but  often  maligned,  phase  at  the  end 
of  the  product  development  process  J 

Will  it  work?  Can  this  change  of  vo 
cabulary  make  a  difference?  No.  if  we 
merely  apply  a  new  word  to  old  ideas  ^  / 

But  yes,  if  we  allow  It  to  change  our  ..  _  _ 

attitudes  toward  the  way  we  think  uDtlity  Coi 
about,  plan,  and  do  software.  ^ -  — 

Michael  D.  Shapiro 
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